> Large changes almost always fail. smaller incremental changes always feel less thrilling, but when you look back over a year, they will accomplish a lot more.

> Large changes almost always fail. smaller incremental changes always feel less thrilling, but when you look back over a year, they will accomplish a lot more. Plus its far easier to course correct. Well, it all depends on the actual stack being used. If you are on dead-horse technologies or superseded dependencies with major breaking changes (e.g. JavaEE, OpenSSL 1.0.x -> 3.x), you can't avoid big changes. Moving fast and breaking things is a way to force changes to legacy systems, where the tech wasn't ready for it (e.g. moving from monolith to microservices)