"no test, a single staging dev server (no local dev env), no doc, inconsistent function and variable naming" --> none of these things prevent code from shipping, per se. I know it's convenient, as a first time leader, to focus on the technical aspects, but from your description, it seems there's underlying
non-technical issues you might want to get familiar with first.
On the technical side, I recommend _listening_ a lot before making any suggestions. _Maybe_ it's all backwards, and there's _always_ a better way to do it, but showing them you understand how they work _first_, then help them push something - even a small win - out of the door _first_ will get you a lot more "street cred" than trying to mandate things out of the gate.
If you're looking for some literature, "Five Disfunctions of a Team" and "Culture Code" are good starting points on how to tackle cultural aspects (and how to be accepted as a newcomer "playing the boss", which will also be your case).
Other than that - leading teams is difficult, leading teams _well_ is an incredibly frustrating/counterintuitive exercise, but a huge growth position :-) Good luck!
On the technical side, I recommend _listening_ a lot before making any suggestions. _Maybe_ it's all backwards, and there's _always_ a better way to do it, but showing them you understand how they work _first_, then help them push something - even a small win - out of the door _first_ will get you a lot more "street cred" than trying to mandate things out of the gate.
If you're looking for some literature, "Five Disfunctions of a Team" and "Culture Code" are good starting points on how to tackle cultural aspects (and how to be accepted as a newcomer "playing the boss", which will also be your case).
Other than that - leading teams is difficult, leading teams _well_ is an incredibly frustrating/counterintuitive exercise, but a huge growth position :-) Good luck!