There are plenty of details in the OP that will be missed. Those who will fail will gloss over those details, will think that some of the advice doesn't apply t

There are plenty of details in the OP that will be missed. Those who will fail will gloss over those details, will think that some of the advice doesn't apply to them, or is "only for bigger companies". I work with people like this. I have felt the pain. To them, the idea of speed means to sacrifice quality and to skip code reviews. Moving fast is not the software engineering equivalent of using a microwave oven to cook. Speed and quality are intertwined. They won't listen, and they won't learn except through failure. The worst is when they tell you what you want to hear during the job interview process because you are a strong candidate, then the reality is the opposite. "We invest heavily in tooling to maximize productivity per engineer", for example. You need to press them for details, don't settle for a sound bite. I think the article has sufficient advice, that if followed, will lead to big enough improvements to be worth it. > "I feel like one success story doesn't necessarily make it good advice for everyone else." I don't think the problem is with the advice giver, rather the receiver.