‘Moving fast and breaking things’ is such a load of crap
Nick Harley

I think the motto fits with a different size of company. If you are a small company you want to establish product-market fit as quickly as possible. You need to think about reaching a healthy cash flow.

You want to quickly deliver features and validate they deliver value. Polish is added later.

I think this makes sense. I’d rather spend optimizing something that delivers value than something that does not deliver value. Change it so it works or kill it. As long as something is not released, you cannot really judge the value it delivers. You want to speed-up the time to market as much as possible. Time is not your friend when your cash flow is insufficient.

The problem is a lot of companies forget to add the polish later and then you end up with a legacy spaghetti monster codebase that drags everybody down. Technical debt accumulates and needs to be paid on time.

When companies get bigger it gets more difficult to move fast. There will be a lot of teams that need to coordinate with each other. So a lot of time is spent to creating an architecture and team structure so people can work as independently as possible from each other.

The need to move as fast is also much lower when companies are bigger. They already have product-market fit and a lot of customers they want to keep happy. The downside risk of poorly developed features is much higher. A poor line of code or a mistake can bring whole platforms down. I have seen it happen before. So these companies need a more sensible approach than “Move fast and break things”.