I think this is overstated. Disruption for the sake of it is often not that helpful in the context of the business (although, in fairness, you do go on to state they often see tech in that context).
I much prefer people who are delivery focused to those who are overly idealistic or want to change everything out of the gate: a good senior understands priorities and knows when to make a trade-off to live with a sub-optimal situation or solution in one area in order to deliver greater value elsewhere.
Do you have problems to solve or not? Often the problem isn't really a problem, except that your current 'solution' is making it so.
I've untied a lot of gordian knots in my career. It really is a thing.
And if you don't have big problems to solve, why do you want a senior developer then? Just hire a junior and keep on going as usual.
Delivery focus is good, till you realise that it's often just delivering status quo for years on end.
That said, nobody is talking about disruption, just wisdom.
It just so happens, sometimes that wisdom will tell you that shipping shit out the door in the name of delivery focus is going to cost you more than its worth in the long run. Calling them overly idealistic to justify your laziness just makes you look bad.
I'd say a truly good senior can tell the difference between a startup and a mature company and adapt accordingly. It takes one set of skills to ship shit out the door as quick as possible and an entirely different set of skills to come in and clean up the mess the kids left behind.
This is why you are selling. Not buying. Because nobody wants to clean up your delivery focused mess.
Because hiring a senior to ignore the problem is a good way to waste a lot of cash.
I also don't appreciate being called lazy, and especially by somebody who knows nothing about my business or my team.
Please try to keep your tone civil in future.
I didn't call you lazy, I said that shipping in the name of delivery focus was lazy, or at least your argument about idealism was.
Fact is, shipping quality is the far more optimal solution and always will be. Making the trade off and adding technical debt is never a worthy trade long term. The only people who gain from it are you and your team. The rest of the company eventually grinds to a halt and begins taking more and more shortcuts around the code which just reinforces everything in a viscous cycle.
You might find this useful:
I was talking about prioritisation. I am very wary (or perhaps jaded) with people who want to fix everything all at once with no regard to the wider effects on the business of doing so.
I didn't mention anything about quality with respect to what we do choose to deliver, although I can assure you that user experience - of which quality is a key facet - is our utmost concern.
I thought my intent was clear, but sorry if not, and hence my comment about overreading. I wrote very little from which you (and you're not the only one) appear to have extrapolated quite a long way.