"Micro" in this case relates to the services scope, not its operational footprint.

So if Netflix has a "User logon" service, and a "payment processing" service, used across their clients clients you might be looking at a couple of "microservice"s with hundreds of related employees. Imagine services for Googles search autocomplete, ML, or analytics...

As the article states the "micro" aspect is mostly in terms of deployment responsibility, freeing those 10-1000 employees from thinking about the totality of Googles/Netflixes' operations before rolling out a patch :)

If "micro" refers to the scope of the service (i.e. very limited feature set), you might still need a team to run it, if the service has to handle a very high volume of transactions or provide very low latency, or both.

The scope of a microservice is commonly a bounded context in DDD. So depending upon the problem you might be talking about a lot of code.

It’s not unreasonable to imagine that any of the examples provided in the source post could require a team larger than 10 people.

Cause it's not very micro?