Take your own example:
> After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.
This right here is a negotiation between business and engineering. The business unit cares about technical debt only if it affects successful delivery of business goals. As such it needs to be negotiated along those lines. In fact, I’d say you make a wonderful negotiation right after:
> So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations?
That is an excellent negotiation right there. The business cares about successful continued operations. Stopping everything to focus entirely on technical debt is not successful to the business. Allocating x% time to a mutually beneficial goal where x can be continuously tweaked is an acceptable point.
> After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project.
The thing about this point is that it is:
A) easy to get setup.
B) well understood enough now to know the benefits to the organization
I’d argue that ci/cd is coming closer to that point now. Definitely is on the right trajectory and for the same reasons. Easy to setup and the benefits are well known and easily understood.
More nebulous topics like testing and tech debt will for the foreseeable future be topics requiring decent negotiation.
[1] I may change my mind on this in the future. Definitely been around on topics where I believe one thing, believe an alternate point of view, and later have a softer or accepting view of the original idea :).
