Most important thing is the environment that allows you instant feedback when developing, which means just one thing:

Ability to run the whole product no your Laptop/in docker and have INSTANT RELOAD, you change something and test it in <5 seconds.

Tests/CI etc can be run when feature is complete and you are making a PR.

Good read, but one major thing instantly comes to mind.

Yes, small teams make for fast teams, but what happens when your dev in a team of 2 leaves? Your 10x speed drops to 0x, or you pull in another 10x dev and they drop to 4x or less (because we all know the seriousness of switching costs).

It may take a while to find an interview a replacement since you need someone that is great, not good.

I prefer to work in smaller teams at smaller companies, but can see why larger companies are large. They care more about consistency than max speed.

I was expecting the article to talk more about the physical environment the developer is in. And it doesn't, which is fine. And it instead talks more about uninterrupted flow time and small teams (like two), and deadlines. It also talks about the codebase being a factor, which not everyone has the luxury of changing. But those other things do seem like food for thought.