Fair, but why is that. I've been talked into just-for-now solutions over and over in my career. Rarely does the org actually go back and clean it up in a timely fashion.
It's possible, regardless of servantness, that leaders don't have a good reputation for following through and finishing things.
Sometimes you should build a raft instead of trying to pretend you can build major infrastructure in no time flat.
I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barriers to adoption with a certain kind of customer for whom a go-kart meets their needs."
I find that the main arguments against the raft/go-kart strategy (from the the business leader) are along the lines of "we need a Ferrari man! not a go-kart; our target customers won't even consider a go-kart".
Its at this point that an very important discussion has to be had about how customer development and barriers to adoption are overcome. BTW - the applies to both new product development and features for existing products.
This is not easy. This discussion must include "Look, the experts who are building this are telling you ________ and ________; you can choose to accept that or continue down a path of uncertainty and investigation until they come up with another set of recommendations...". The goal for the technical leader is to setup a set of options for the business leaders to choose - none of which are allowed to be chaos.
If chaos is the norm, either the business leader or technical leader will be removed - or the business will likely fail due to that chaos and its effects on the team.
In the above context, I'm talking about the people we hire to do the things that need to get done to move a business forward - we hire them for their expertise and skills.
When I'm talking about the people I've hired - to management, peers in other groups etc - I refer to them as "the experts who are building the ________, tasked with accomplishing ________" and so on. It reminds people that they're here for a reason - to contibute ..and not here by random coincidence.
Far too many confuse the two, and the discipline and flexibility needed for both.
Many topics follow a theme: leave us developers alone, we are working. Do not negotiate with our estimates, etc.. This may not work in the real world. When a project involves several teams (one builds hardware, second UI, third computation, fourth preps algorithms and tools for analysis, etc.), there are common test events and mid-course corrections. Blowing past schedule affects others -- canceling a test event for a geographically distributed team is expensive.
In such cases when the developer says that they need an extra 2 months do X, "what can you do in 2 weeks" is a reasonable counter question. It may be an unreliable junk and those 2 weeks of work will have to be tossed and redone, but this may still be the best option in the grand scheme of things. Here developers often dig in and start throwing articles and links on technical debt; making them finally write a quick, limited capability prototype is a MAJOR effort. My 2c.