About your Point 2. I work as a senior developer/architect with ca. 15 years of experience. Crucially, I’m working at a company with extremely long product life cycles. (Our flagship product is from the early Nineties!) Here is why your Point 2 is very dangerous: Of course you need your MVP quickly. But if you don’t soon clean up your architecture etc. to be as good as you can make it, you get irreversible friction that can reduce your team velocity for _decades_ to come. To some extent, this is currently happening to my company. We are loosing market leadership because competitors can crank out features faster because they cleaned up their act in time. So when a manager or PO or PM tells me I should keep an eye on the business (which I do!), I ask back: “What do you mean by ‘business’? The next quarter, the next year, the next two or five years?“ Because the engineering strategy hinges critically on the answer here.

I am not alone with this view. I remember an interview with Larry Page where he explicitly stated the business horizon should be at least the next five years, and that long-term view is a key to Google’s success.

Theoretical computer scientist and software engineer. Born in Germany.