+1 for this. Unless you've been hired specifically to help them change their dev practices, I'd go along with what they have until you've got some understandin

+1 for this. Unless you've been hired specifically to help them change their dev practices, I'd go along with what they have until you've got some understanding and reputational-clout to start suggesting such huge changes to how everyone works. Rocking up and on day one start asking people to change their development practices (particularly around branching policy which is something very contentious and/or strict everywhere I've been) because "It makes my work easier" is a sure-fire way to get people's backs up and dislike you. And where do you stop? First it "It makes my work easier" to change the dev practices, but why not start demanding that everything is rewritten in Go/Vue.js/Haskell? It'll make your work easier. How about we change the product from a Desktop App to a web app? It'll make your work easier. Why dont we just sub-contract the whole thing out to off-shore teams? It'll make your work easier. There might be a case for any of those, but I'd personally wait (and I would prefer any hires I bring in also wait!) until the right time before advocating for massive sweeping changes right away. tl;dr - Arrogance & know-it-alls can be disruptive (in a bad way). It takes a village and flexibility is key to working with any team.