> They were skipping all the good software engineering basics.
Who decided the things you are pushing have anything to do with "good software engineering basics"?
Just because someone says it's cool thing to do, it doesn't mean it is, and it also doesn't mean it will produce good result in particular environment.
Look at it through Chesterton's fence - if team was able to produce good results without the "good software engineering basics", it may harm it. Thats' why you are rejected, and if I may - rightfully so.
I am too old to observe teams with amazing productivity - and any "good software engineering basics" would have destroyed it very quickly.
As a piece of advise - I would discuss with the TEAM first - what is their opinion about pending issues and how THEY would suggest to rectify it. Talk through suggestions, see what actually may help. Have them onboard instead of shoving off their face some smarty-pants management tactics you have read the other day in expensive book.
Guaranteed, if you put your ego aside, get to listen, and adopt solutions that solve actual problems instead of "code review (or whatever-cool-thing) is cool" - you will get on track very fast.
You think "code reviews, tests, CI, and issue tracking" are just "things that someone said are cool to do"? Your argument is genuinely that these do not broadly fall under the umbrella of "good software engineering basics"?
The problem here is classical - for someone with a hammer every issue looks like a nail.
Are those cool things may be beneficial for some abstract project. It certainly may be.
Will those things be good for any project? Certainly not.
How do you think software development existed before all those things were invented? Code was better, systems were more reliable. And there were no managers solving “issues “ with buzzwords
Those items add overhead, are hard to add to some existing systems after the fact. Issue tracking is very important if you have someone creating the issues. A lot is going wrong here that some of the elements you suggest could help but by themselves probably not.
> This situation caught up with them in the past few months with many outages that caused close $1m USD in damages. Thus why leadership felt they needed a tech lead to steer the ship.
The million dollar outage is probably a tall tail but passed around the management table as blame everyone can agree with because that group isn't represented.
Who decided the things you are pushing have anything to do with "good software engineering basics"?
Just because someone says it's cool thing to do, it doesn't mean it is, and it also doesn't mean it will produce good result in particular environment.
Look at it through Chesterton's fence - if team was able to produce good results without the "good software engineering basics", it may harm it. Thats' why you are rejected, and if I may - rightfully so.
I am too old to observe teams with amazing productivity - and any "good software engineering basics" would have destroyed it very quickly.
As a piece of advise - I would discuss with the TEAM first - what is their opinion about pending issues and how THEY would suggest to rectify it. Talk through suggestions, see what actually may help. Have them onboard instead of shoving off their face some smarty-pants management tactics you have read the other day in expensive book.
Guaranteed, if you put your ego aside, get to listen, and adopt solutions that solve actual problems instead of "code review (or whatever-cool-thing) is cool" - you will get on track very fast.
All the best