[iajrz]

Sadly, no. I've not seen, say, using legacy source code management tools or development lifecycles described as technical debt; I'd not thought about it that way myself, I'd just thought about it as outdated practices. A quick hack or an ugly workaround? Yes - and even those I've rarely seen management allocate time to pay back. Reframing the other issues may help communicate with management on how to make all the process and product better.

[adamconroy]

And quite possibly the whole system was replaced within a few years and it turned out that management were correct in not letting your team waste the organization's money trying to be purists, and probably over-engineering at the same time.

[iajrz]

I see how you'd imagine that, but it's not so. It wasn't about purism or over-engineering - it was actually sensible stuff. Less like "let's use latest version of framework X" or "let's change the organization's stack!" and more like "Let's set up this new project in a supported version of the JVM instead of reinstalling the legacy one in the new server, please? I looked it up and this newer version of the JVM is certified to work properly on that platform." Or like the time I tried to get a certain organization to take up version control, which was rejected because someone sometime way back when managed to lose information while merging in cvs and the supervisor didn't feel comfortable with a vcs, distributed or not (I'm told merges are still done manually by the supervisor using windiff).

And I offered to do the work necessary on my own time on both these occasions, with safeguards so we could fall back into the status quo at the slightest signal of trouble.

So no, while I can be - and am - passionate about new tech, I cut my teeth developing large scale systems that had to be up at all times. So being conservative at work is second nature to me, even if I play with unstable or experimental stuff all the time.

It's... not cool that you tried to be clairvoyant instead of curious.

Maybe in the future you could ask "How did that turn out though? Were the systems changed, that you know of? Did you consider that management didn't want the team to waste the org's money trying to be purists or over-engineering? Did the decision maker have a technical background?" or other such questions, in order to later make an informed statement.

On the other hand, the way you stated it made me think you've had an awesome experience with great management, so congrats on that, I hope you keep choosing amazing teams to join - if or when you change gigs :^)